安装 Nginx 并将其配置为反向代理服务器

适用于： .NET Core 2.1、.NET Core 3.1、.NET 5

本文介绍如何安装 Nginx 并将其配置为反向代理服务器。

若要按照本部分中的练习操作，必须创建一个 ASP.NET Core Web 应用程序并将其部署到 /var 文件夹。

在上一部分中，你使用 .NET CLI 工具创建了 ASP.NET Core Web 应用程序，并将应用程序部署到 /var 文件夹。 应用程序还配置为侦听 HTTP 请求的端口 5000，并删除了 HTTPS 重定向。

此时，客户端应在连接到应用程序 (（例如 http://localhost:5000) ）时提供端口号。 但是，这不是所需的行为。

本部分的目标如下所示：

在下一部分中，你将使用 Nginx 作为代理服务器，改为将发送到端口 80 的 HTTP 请求路由到 .NET 应用程序。 你还将将应用程序配置为自动启动。

Nginx 是一种常用、轻型且快速的 Web 服务器。 它可以在 Linux 和 Windows 上运行，并且可以配置为反向代理服务器。

Nginx 作为 守护程序运行。 守护程序是后台运行的服务的替代术语。 与在 Windows 上运行的服务一样，可以将守护程序配置为在启动期间自动启动。 将 ASP.NET Core应用程序配置为以守护程序身份运行。

安装 Nginx 非常简单。 运行命令 sudo apt install nginx 以在 Ubuntu 虚拟机上安装程序。

安装完成后，运行 whereis nginx 以发现程序的安装位置。 可以通过检查输出来查看 Nginx 配置文件的位置。 以下屏幕截图显示配置文件位于 /etc/nginx 文件夹中。

注意

如果运行 Ubuntu 或 Debian 以外的分发版，则可以从 官方 Nginx 安装文档中找到等效的包管理器安装命令或说明。

如果没有看到 Nginx 正在运行，则可以通过运行 sudo systemctl start nginx来显式启动它。 尽管本练习将演示 systemctl Nginx 的命令，但这些命令用于将 Web 应用程序配置为以守护程序自动启动。

安装完成后，Nginx 已配置为自动启动。 Nginx 作为守护程序运行。 可以使用 systemctl 检查守护程序的状态。

该 systemctl 命令用于管理显示服务状态或启动和停止服务等任务的“服务”。 某些可用参数包括启动、停止、重启、启用、禁用和状态。 若要检查 Nginx 的状态，请运行 systemctl status nginx。

此命令生成一些有用的信息。 如此屏幕截图所示，Nginx 处于 active (running) 状态，Nginx 实例的进程 ID 为 8539。 另请注意和enabledvendor preset: enabled语句。 Enabled 表示在重启计算机时将启动此守护程序，这意味着 vendor preset: enabled 在安装 Nginx 时默认启用了 Nginx。 因此，当服务器启动时，Nginx 将自动启动。

默认情况下，Nginx 侦听端口 80。 因为它正在运行，因此在浏览 localhost 时，应该能够访问 Nginx 的主页。 用于 curl 通过运行 curl localhost来测试 Nginx。 以下屏幕截图中突出显示的黄色文本显示了 Nginx 默认网页。 因此，Nginx 正在运行：

服务或守护程序可以通过使用命令 systemctl 进行管理。 启动、停止或进行更改需要超级用户访问权限。 因此，必须将前缀添加 sudo 到这些命令。

可能必须不时重启守护程序。 若要重启守护程序，请运行 sudo systemctl restart 。 若要重启 Nginx，请运行 sudo systemctl restart nginx。 请确保在运行此命令之前和之后检查 Nginx 的状态，以监视对进程 ID 的更改。

若要停止守护程序，请运行 sudo systemctl stop 。 若要停止 Nginx，请运行 sudo systemctl stop nginx，然后再次运行 systemctl status nginx 来检查 Nginx 的状态。 这一次，该服务显示为非活动 (死) 但仍已启用。 这意味着，尽管服务未运行，但它将在服务器重启后自动启动。

注意

该 systemctl status 命令还会显示守护程序的多行以前的日志条目。

停止 Nginx 后，再次运行 curl localhost 。

注意

连接被拒绝，因为没有任何内容在侦听端口 80 上的传入流量。

禁用守护程序不同于停止守护程序。 禁用的守护程序可能正在运行，但在服务器重启后不会自动启动。 若要禁用 Nginx 守护程序，请运行 sudo systemctl disable nginx，然后检查 Nginx 的状态。

此屏幕截图显示 Nginx 未运行且已禁用。 这意味着 Nginx 不会在重启后自动启动。

若要启动守护程序，请运行 sudo systemctl start 。 若要启动 Nginx，请运行 sudo systemctl start nginx该服务，然后再次检查服务的状态。

此屏幕截图显示 Nginx 已启动，但仍处于禁用状态。 尽管服务正在运行，但 Nginx 不会在重启后自动启动，因为它是已禁用的服务。

启用服务意味着它将在重启后自动启动。 若要启用 Nginx，请运行 sudo systemctl enable nginx，然后再次检查 Nginx 的状态。

此屏幕截图显示 Nginx 正在运行，并且将在服务器重启后启动。

了解如何启动、停止和重启 Nginx 服务后，接下来将 Nginx 配置为反向代理，以便将端口 80 上发出的请求路由到侦听端口 5000 的 ASP.NET Core应用程序。

下面是所需的配置。 突出显示了一些关键部分。

此配置指示以下内容：

注意

server_name _代码中的行。 这用作 catch-all 指令。 若要详细了解 server_name，请参阅 官方文档。

配置更改看起来很简单。 我们将使用此代码替换 server 配置文件中的指令部分。 但是配置文件在哪里呢？

主 Nginx 配置文件为 /etc/nginx/nginx.conf. 若要检查配置，请使用该 cat /etc/nginx/nginx.conf 命令并搜索服务器指令。

滚动浏览配置以找到服务器指令。 应该不会找到它。 我们可以将所需的配置更改放在配置文件的某个位置。 但是，理想情况下，你不希望替换原始配置文件。 这是为了防止引入可能阻止服务器正确启动的配置错误。 该 server 部分不在主配置文件中。 如果继续滚动浏览配置文件，则会发现存在一些 include 指令。

通过将配置拆分为要包含在主配置文件中的区块，Include 指令可以更轻松地管理配置。 主配置文件可以保持简单，某些特定的配置部件可以移动到其他文件。 此屏幕截图中突出显示的行指示以下内容：

如果检查这些目录，则在 /etc/nginx/conf.d 中找不到任何配置文件。 但是，已 启用 /etc/nginx/sites 的一个文件。

默认配置文件看起来是用于托管所需配置的主要候选文件。 If you inspect the /etc/nginx/sites-enabled/default file by using cat /etc/nginx/sites-enabled/default, you would see that the default server directive is put within the following code.

因此，必须编辑 /etc/nginx/sites-enabled/default 文件才能更改配置。

你已了解在编辑 Startup.cs 文件以从 ASP.NET 管道中删除 HTTPS 重定向时如何编辑文件。 现在，你将再次使用 vi 更改 nginx 配置文件。

提示

始终备份要更改的文件。 如果编辑后出现问题，可以使用该副本将文件还原到以前的状态。 在这种情况下，请运行 cp /etc/nginx/sites-enabled/default ~/nginx-default-backup 以将配置文件复制到主目录。 备份文件名将为 nginx-default-backup。 请注意，备份不是在原始文件所在的目录中进行的。 这是因为 Nginx 加载了该目录中的所有配置文件，并且你不想通过加载两个不同版本的服务器指令来中断配置。

运行 sudo vi /etc/nginx/sites-enabled/default 以编辑配置文件并替换服务器指令，如以下屏幕截图所示。

下面是使用 vi 编辑文件的一些提示和技巧：

更改现已保存，必须重启 Nginx 服务才能使这些更改生效。 在重新启动服务之前，可以运行 sudo nginx -t 命令来测试配置文件。 此命令运行时，Nginx 会检查配置文件语法，然后尝试打开配置文件中引用的文件。

如此处所示，已更改的配置文件似乎是正确的。

我们必须重启 Nginx，以便更改生效：

重启后，当向 http://localhost 发出请求时，预期会看到来自 ASP.NET Core应用程序的响应，因为 Nginx 应充当对端口 80 发出的请求的反向代理。

重启 Nginx 服务以使更改生效，然后通过运行 curl localhost向 localhost 发出请求。 但是，此命令将失败。 下一步是运行 wget localhost，然后搜索有关问题的根源的一些提示。

在前面的屏幕截图中，你将看到以下信息：

第一行和第二行指示你能够解析 localhost 并在套接字上 127.0.0.1:80 连接。 因此，Nginx 应正在运行。 若要验证这一点，可以运行该 systemctl status nginx 命令。

第三行指示问题的根源。 收到 HTTP 502 错误网关 错误消息。 HTTP 502 错误网关 与代理相关。 这意味着反向代理无法连接到后端应用程序。 在这种情况下，应在端口 5000 上运行和侦听请求的 ASP.NET Core Web 应用程序。 我们应该检查 Web 应用程序是否也在运行。

若要开始故障排除，请运行与之前相同的 netstat 命令。 这一次，使用 grep 筛选应用程序的端口 5000。 然后，运行 netstat -tlp | grep 5000。

此示例输出指示没有任何内容在侦听端口 5000。 因此，这是来自 Nginx 的 HTTP 502 响应的原因，因为它可以找到侦听端口 5000 的进程。

解决方案是启动 ASP.NET Core应用程序。 但是，在进一步操作之前，可以查看另一种方法来排查此问题。 并非每个问题都很容易解决，只需查看几行日志内容并找到根本原因即可。 有时，必须深入了解其他系统和应用程序日志。

由于在 Linux 中设置 ASP.NET Core应用程序时与 Nginx 密切合作，因此建议你了解 Nginx 和操作系统提供哪种类型的日志来进行故障排除。

如果再次运行 cat /etc/nginx/nginx.conf ，然后查找， logging settings应注意以下内容。

这表明 Nginx 有两种类型的日志：访问日志和错误日志。 这些存储在 /var/log/nginx/ 目录中。

访问日志类似于 IIS 日志文件。 对内容的快速检查显示它们类似于以下屏幕截图。

访问日志不会显示你已知道的 HTTP 502 响应状态以外的新信息。 还可以通过运行 cat /var/log/nginx/error.log来检查错误日志。 这些都揭示了有关问题原因的更多信息。

指示很明确：Nginx 可以从客户端获取请求，但无法连接到upstream应在该端口上运行和侦听的 ASP.NET Core应用程序的服务器http://127.0.0.1:5000。

若要解决此问题，请手动启动 ASP.NET Core应用程序。 使用第二个终端会话连接到服务器，然后像以前一样运行 ASP.NET Core应用程序。

在运行 ASP.NET Core应用程序时，切换到另一个终端会话，并运行相同的curl localhost命令。 现在，可以访问在 Nginx 后面运行的 ASP.NET Core应用程序。 以下屏幕截图显示你向 localhost 发出请求，请求由 Nginx 处理并路由到后端应用程序，并且你收到了来自 ASP.NET Core应用程序的响应。

现在，你已将 Nginx 配置为在 Linux 中运行的 ASP.NET Core应用程序的反向代理。

但是，如果 ASP.NET Core应用程序在重启后未启动，结果会怎样？ 如果 Web 应用程序崩溃，直到你注意到它未运行，才启动，会发生什么情况？ 每次重启进程终止后，是否应启动 ASP.NET Core应用程序？

第 2.3 部分 - 将 ASP.NET Core应用程序配置为自动启动

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。